WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 6 : 




(11) International Publication Number; 


WO 97/24879 


H04N 7/173 


Al 










(43) International Publication Date: 


10 July 1997 (10.07.97) 



(21) International Application Number; PCT/US96/20132 

(22) International Filing Date: 23 December 1996 (23.12.96) 



(30) Priority Data: 

08/580,160 



28 December 1995 (28.12.95) US 



(71) Applicant: TELE -COMMUNICATIONS, INC. [US/ US]; 5619 

DTC Parkway, Englewood, CO 801 1 I (US). 

(72) Inventors: RUTOWSKI, Steve; 5485 S. Cathay Way, Aurora, 

CO 80015 (US). RIERDEN, William; 6235 Sanders, 
Evergreen, CO 80439 (US). 

(74) Agents: GATTO, James, G. et al.; Baker & Bolts, L.L.P., The 
Warner, 1299 Pennsylvania Avenue, N.W., Washington, DC 
20004 (US). 



(81) Designated States: AL, AM, AT, AU, AZ, BA, BB, BG, BR, 
BY, CA. CH, CN. CU, CZ, DE, DK. EE, ES, Fl, GB, GE, 
HU, IS, JP. KE, KG, KP, KR, KZ, LC, LK, LR, LS. LT, 
LU, LV, MD, MG, MK, MN, MW, MX, NO. NZ, PL, 
PT, RO, RU, SD, SE, SG, SI, SK, TJ, TM, TR, TT, UA, 
UG, UZ, VN, ARIPO patent (KE, LS, MW, SD, SZ, UG), 
Eurasian patent (AM, AZ, BY, KG, KZ. MD, RU, TJ, TM). 
European patent (AT, BE, CH, DE, DK, ES, FI, FR, GB, 
GR, IE. IT, LU, MC, NL, PT, SE), OAPr patent (BF, BJ, 
CF, CG, CI, CM, GA. GN, ML, MR, NE, SN. TD, TG). 



Published 

With international search report. 



(54) Title: METHODS AND SYSTEMS FOR CLIENT OR CUSTOMER-SITE TRANSACTION PROCESSING IN A DISTRIBUTED 
DATABASE SYSTEM 




(57) Abstract 

Distributed database system for processing a client or customer-site initiated database transaction includes a transaction keying and 
RF transmitting device (210) and a transaction relay (219) for transmitting the client or customer-site initiated database transaction, a local 
order RF receiver converter for receiving the transaction and converting the transaction to a computer readable format, and a modem for 
linking the transaction in a persistent queue (232), which initiates a database transaction, including information identifying service location 
equipment and desired product and transmits the transaction to the queue. A client server retrieves the transaction from the queue and 
transmits the data to a data directory server, including a rules database, and the data directory server interrogates at least one of a plurality 
of dispatch utility servers to identify an available dispatch utility server and routs the transaction to the available dispatch utility server. 



BN80OCID: <WO_j972407ttA1 J_> 




FOR THE PURPOSES OF INFORMATION ONLY 

Codes used to identify States party to the PCT on the front pages of pamphlets publishing international 
applications under the PCT. 



AM 


Armenia 


GB 


United Kingdom 


MW 


Malawi 


AT 


Austria 


GE 


Georgia 


MX 


Mex ico 


AU 


Australia 


GN 


Guinea 


NE 


Niger 


BB 


Barbados 


GR 


Greece 


NL 


Netherlands 


BE 


Belgium 


HU 


Hungary 


NO 


Norway 


BP 


Burkina Faso 


IE 


Ireland 


NZ 


New Zealand 


BG 


Bulgaria 


IT 


Italy 


PL 


Poland 


BJ 


Benin 


JP 


Japan 


PT 


Portugal 


BR 


Brazil 


KE 


Kenya 


RO 


Romania 


BY 


Belarus 


KG 


Kyrgystan 


RU 


Russian Federation 


CA 


Canada 


KP 


Democratic People's Republic 


SD 


Sudan 


CF 


Central African Republic 




of Korea 


SE 


Sweden 


CG 


Congo 


KR 


Republic of Korea 


SG 


Singapore 


CH 


Switzerland 


KZ 


Kazakhstan 


S! 


Slovenia 


CI 


C6te d'l voire 


LI 


Liechtenstein 


SK 


Slovakia 


CM 


Cameroon 


LK 


Sri Lanka 


SN 


Senegal 


CN 


China 


LR 


Liberia 


SZ 


Swaziland 


cs 


Czechoslovakia 


LT 


Lithuania 


TD 


Chad 


cz 


Czech Republic 


LU 


Luxembourg 


TG 


Togo 


DE 


Germany 


LV 


Latvia 


TJ 


Tajikistan 


DK 


Denmark 


MC 


Monaco 


TT 


Trinidad and Tobago 


EE 


Estonia 


MD 


Republic of Moldova 


UA 


Ukraine 


ES 


Spain 


MG 


Madagascar 


UG 


Uganda 


FI 


Finland 


ML 


Mali 


US 


United States of America 


FR 


France 


MN 


Mongolia 


uz 


Uzbekistan 


GA 


Gabon 


MR 


Mauritania 


VN 


Viet Nam 



BN8DOCID: <VW0_9724S7flA1 JL> 



WO 97/24879 




PCT/US96/20132 



METHODS AND SYSTEMS FOR CLIENT OR 
CUSTOMER-SITE TRANSACTION PROCESSING 
IN A DISTRIBUTED DATABASE SYSTEM 

BACKGROUND OF THE INVENTION 
5 1. Field of the Invention 

The present invention relates to methods and systems for client or 
customer-site processing of transactions in a distributed database system. 

2. Description of Related Art 

The popularity of cable television has grown rapidly over the past two 
10 decades. This popularity has been driven in part by the improved reception 
quality offered by cable systems. Perhaps, more important to the success 
and growth of cable television, however, has been the increased variety of 
programming available to consumers. 

Cable television may be sold as a basic package of channels, which 

1 5 may then be augmented by additional channels or subpackages of channels, 
ej^, premium packages containing one or more additional channels. 
Generally, the sale of such packages of channels does not rely on direct 
personal contact between a salesperson and a potential subscriber. Initial 
cable subscriptions may result from exposure to cable television at a 

20 relative's home or the home of an acquaintance. The subscriber usually 
solicits a basic package from his or her local cable television provider. The 
premium packages may also be sold in this manner or they may be also sold 
through advertisements on the channels of the basic package or through 
direct mailings to current subscribers, such as through promotional materials 

25 included with billing statements, and to past subscribers. 

Nevertheless, an effective method of marketing the channels 
of the premium packages may be during promotional offerings, i.e. . 
particular days, weekends, or portions of weekends during which free 
program viewing time is offered. These provide the opportunity for basic 
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package subscribers to preview available programming. Frequently, these 
promotions include the opportunity for non-subscribers to subscribe to a 
premium channel at a reduced or introductory rate during the promotional 
period. Regardless of the marketing method, however, orders for cable 
5 television products or packages are commonly placed by preparing a paper 
order form, which is then manually processed. Such forms may be prepared 
by a cable television technician during an installation or maintenance visit 
or by telephone operator at a local cable television office. 

In addition to the basic and premium packages described above, there 
10 is an ever growing market for the purchase of cable television access to 
individual events, e^, boxing matches, movies, and the like. These "pay- 
per-view" options allow subscribers to tailor their cable television subscriber 
to their particular viewing desires. However, the increasing number of 
choices and options available to the cable television subscriber has also 
15 created a demand for increased flexibility in system design and increased 
speed and capacity for transaction processing. 

With the increasing demand for the rapid processing of transactions, 
as well as the ever-increasing size of databases in which these transactions 
are processed, many cable television suppliers have turned to distributed 
20 database systems to satisfy this demand. As herein discussed, the term 
"distributed database" refers to a database system in which data may be 
located in more than one physical location or in more than one database, or 
both. In some cases, data is distributed, such that certain data is located in 
only one database while other data is located in more than one database. 
25 Often, more than one client/customer or user needs to access the data at the 
same time. In addition, many requesters desire simultaneous or near 
simultaneous access. This presents a problem in that only a limited number 
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of access requests may be processed at one time. 

Access requests to databases generally are one of two types. The first 
is termed a "query" and is associated with a request to read data from a 
database or databases. The second is termed an "update" and is associated 
5 with a request to write data to a database or databases. For purposes of this 
discussion, both types of requests (and combinations thereof) are referred to 
generally as a "transaction." It is to be understood, however, that a 
transaction may involve one or more of either, or both, types of requests. 
Various problems have been encountered with distributed database 

10 systems such as those described above. For example, in some cases, 
multiple requesters may request access to particular data at the same time. 
Typically, each data server may process one transaction (or a series of 
related transactions) at a time. Thus, if multiple transactions are delivered 
to one server, e^, a collection of databases or a conduit to one or more 

15 databases, at the same time, not all of the transactions may be processed at 
the same time. When this occurs, the later transactions are queued or must 
be resubmitted. This causes undesirable delays in the processing of these 
transactions. Other factors also contribute to delays in processing such 
transactions. As a result, in some cases, one or more data servers may be 

20 idle while another is backlogged with multiple transactions. This is an 
inefficient use of resources. 

In an attempt to address these problems, systems may employ a 
variety of different schemes in an effort to balance the distribution of 
transactions among multiple servers. According to one arrangement, 

25 particular requesters are permanently assigned to particular servers. The 
theory behind such a design is that by randomly limiting the number of 
requesters accessing a particular data server, some minimization of the 
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••bon^eck" effect may be achieved. According t o another approach 
multiple copies of particular dati, are stored in more than one database This 
reduces the likelihood that destred data will be unavailable. 

These schemes, however, generally suffer from at least toe 
5 drawbacks. Fta. if systems elect the firs, scheme, particular requesters are 
"hard-wired" to particu.ar servers, ta such systems, requesters do no, have 
access ,„ the full complement of servers available in the system, winch are 
capab.e of processing a particular transaction As a resul,, uneven load 
d.stnbution still may occur, and a server, which is free ,o service a 
10 transaction, may no, be caHed upon ,„ do so because the requester may not 
have access to the free server. A second drawback ,„ the data distribution 
schemes described above is the significant time and cos, of processing 
^formation in order to determine me best method by which to allocate data 
transactions. In some cases, particularly when me number of transactions to 
1 5 be processed is low and me complexity of the allocation scheme is high 
these sys,ems may perform more efficiently without a real-time decisional' 
process. Third, m the case of d.stributed database systems contaming 
redundan, da,a fcg. the second scheme,, the avai.ab.lity 0 f seconda^ 
storage fefc disk storage) is s.gruficantly decreased by vutue of the 
20 redundancy of me da„ Often, however, adequate data redundancy is no, 
poss,b.e because of limitations in storage capacity imposed by a data 
storer/provider. 

The cable television industry, and the telecommunications industry 
u. general, has a need for the abil.ty and capacity to store and marupu.ate 
arge amounts of data. Cable system operators typically matntatn large 
databases contacting a variety of subscriber, product billing information 
and the Idee. Typical classes of information managed by cable companies 
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may include subscriber accounts, on-site equipment, and current and past 
selections, available products and their pricing structure, physical assets and 
their functionality, and marketing and promotion data. It is often desirable 
to distribute this information across a network of databases whether or not 
5 they are located at the same physical location. 

The processing requirements for cable-based systems may be 
staggering. For example, it may be necessary to provide 24 hour a day 
service, 7 days per week, for a subscriber base including millions to tens of 
millions of subscribers. In addition, such a system may be called upon to 
10 execute hundreds or thousands of transactions per second (TPS). In 
addition, such systems may be called upon to support thousands of 
interactive requesters operating transaction generators ( e.g. . Customer 
Service Representatives (CSRs)) many of which may be concurrent 
requesters. Assuming about 15 million subscribers, it is further anticipated 
15 that the average customer record may soon be on the order of about 15 
kilobytes requiring a total database capacity of about 225 gigabytes. 

In an example of a distributed database system that may be employed 
by a cable system operator, a plurality of transaction generators or terminals 
may be operated by CSRs to acquire access to data contained within the 
20 system. Each of the transaction generators communicates either directly or 
indirectly through a communications controller with a particular associated 
server or group of servers. Communication techniques and protocols which 
are known in the art are employed to allow the transaction generators to 
communicate with these servers. For example, Ethernet™ may be used 
25 when both requester and server are PC-based processors. 

In such systems, difficulties may arise when access to data residing 
at differing physical locations is required. This places a burden on the CSR 
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(or the transaction generator, in general) because it may impose add.tional 
processing requirements to keep track of which data is accessible to a 
particular CSR and which is not. Additionally, if certain data is needed but 
not accessible to a particular CSR, it may be necessary to determine where 
5 that data is located and which CSR may have access to it. 

An example of such a system exhibiting the drawbacks described 
above may include four data processing centers to support a national cable 
system operator. Each of four geographical regions in the United States (e^ 
Northeast, Southeast, Midwest, and West) may be supported by one of the 
10 four data processing centers. In such a case, all records for subscribers of the 
system operator who reside in Pennsylvania might be stored at the Northeast 
data center in its associated database. In the event that a particular 
Pennsylvania subscriber is at home and desires to change, re,, ena ble or 
disable, a channel, event, or premium package. The subscriber may contact 
15 a CSR operating a transaction generator connected with the Northeast 
database. The CSR, using the transaction processor, may simply generate a 
request for information regarding that subscriber. Alternatively, the 
subscriber may contact an Automatic Response Unit (ARU) having an 
Automatic Number Indicator (ANI) interface and a similar request for 
20 information could be generated automatically. 

The method of distribution of customer records in the above example 
is known as horizontal data distribution. In this example, each of the 
subscriber records is completely contained on one physical server while the 
whole of its associated database and the enterprise domain of all subscribers 
25 is spread across all servers. Such data may also be distributed in a vertical 
manner wherem different aspects of a subscriber's account resides on 
different physical servers. 
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SUMMARY OF THE INVENTION 

A need has arisen for a distributed data base system capable of 
efficient, client or customer-site processing of data transactions. It is further 
desirable that the system be flexible, expandable, and cost efficient. 
5 In addition, it is an object of the current invention to provide a 

distributed database system capable of high speed transaction processing. 
It is a yet further object of the invention to allow database access while 
eliminating the need for time consuming processes previously associated 
with such access. It is a still further object of the invention to provide server 
10 selection based upon a rules base allowing fast and efficient access to 
distributed information. 

An embodiment of the invention is a distributed database system for 
processing a client or customer-site initiated on-line database transaction. 
The system comprises a transaction generator, which initiates at least one 
1 5 database transaction, including information identifying client or customer- 
site equipment and a desired product, and transmits the at least one 
transaction to a dispatcher means for tracking a geographic location of the 
generator, for routing each of the at least one transactions to a geographic 
system, and for queuing each of the at least one transactions within a queue, 
20 e^g,, a persistent queue, and transaction transfer means for retrieving the at 
least one transaction from the queue and transmitting said at least one 
transaction to interrogation server means. The server interrogation means for 
interrogating data extraction means extracts the information identifying the 
client or customer-site equipment and the product from the transaction, 
>5 formulates an addressability change transaction, and transmits the change 
transaction to the server interrogation means. The server interrogation 
means transmit the change transaction to an addressability change means for 
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■denttiymg controller means for enabling and disabling the desired product 
and for mstiucrtng the controller means .o update the status of the product' 
Another embodiment of the invention ,s a distributed database system 
for processus a client or customer-site, ejfc, in . hom e, initiated on-l,„e 
. database transaction. The system may compnse a portable faction 
generator, which initiates a database transaction, for example, by means of 
a remote procedure caH (RFC), deluding utforrnation identifying client or 
customer-site equipment and a desired product and transmit, the transaction 
to a queue, ejfc, a persistent queue. For example, the transaction generator 
may comprise a local order RF tiansmitter for transmitting the diem or 
customer-sire initiated on-line database transaction, a local order RF 
recerver-converter for receivutg th e transaction and converting the 
transaction to a computer readable format, and a modem for data linking the 
transaction to the queue. Further, the local order transmitter may tnclude a 
transaction keying and RF transmitting device and a transaction RF 
transmission relay device. A client message server (CMS) retrieves the 
transaction from the queue and transmits the transaction to a data dtrecory 
server (DDS). The DDS tnterrogates at leas, one of a plural.ty of dispatch 
utilay servers (DUS) to identify an available DUS and routes the transaction 
to the available DUS. The available DUS exti^ts the information identifying 
the chen, or customer-site equipment and the product from the transaction 
formulates an addressability change transaction, and transntits the change 
transaction to the DDS. The DDS then transmits the change transaction 
through an addressability open server. Finally, the addressability open 
server tdentifies a controller based on the tdentif.ed client or customer-s.te 
equrptnent, which controls enabling and disabling the desired product and 
utstructs the controller to update the status of the product with respect to a 
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particular client or customer. 

The DDS may have access to or may include a rules database 
controlling the interrogation of the at least one of a plurality of DUSs by the 
DDS to identify the available DUS. Further, the plurality of DUSs may 
5 operate in parallel to process a plurality of the database transactions 
concurrently, and the plurality of DUSs also may operate in parallel to 
formulate a plurality of addressability change transactions, e.g.. RPCs, 
concurrently. In addition, the system may include a plurality of controllers 
which may operate in parallel to process a plurality of database transactions 
10 concurrently and whereby an appropriate series of addressability change 
RPCs are formulated based on the client or customer-site equipment 

Still another embodiment of the invention is a method of processing 
client or customer-site initiated on-line data transactions. The method may 
comprise the steps of initiating a data transaction, including information 
15 identifying client or customer-site equipment and a desired product, at a 
client or customer-site and transmitting the transaction to a queue, e^, a 
persistent queue. Such transactions may comprise RPCs. The transaction 
may later be retrieved from the queue, and the transaction then may be 
transmitted to a DDS. At least one of a plurality of DUSs is then 
>0 interrogated by the DDS to identify an available DUS, and the transaction 
is routed to the available DUS. The information identifying the client or 
customer-site equipment and the desired product is next extracted from the 
data transaction, an addressability change transaction is formulated, and the 
change transaction is transmitted to an addressability open server. A 
5 controller is then identified, which controls enabling and disabling the 
desired product with respect to a particular client or customer, and the 
controller is instructed to enable or disable the product. 
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As noted above, the plurality of DUSs may operate m parallel to 
process a plurality of the database transactions concurrently and to formulate 
a plurality of the addressability change transactions concurrently. Further 
the method may include the step of establishing rules whereby the 
5 interrogation of the at least one of a plurality of DUSs by the DOS to 
identify the available DUS is controlled. The method may also employ a 
plurality of controllers operating in parallel to process a plurahty of the 
database transactions concurrently, and whereby an appropriate 
addressability change RPC may be formulated based on the client or 
10 customer-site equipment. 

It is an object of the system of the present invention that a cable 
techmcian/client may accomplish on-line order processmg and transaction 
completion tasks while in a client's or customer's home or at his or her place 
of business. It is a feature of this system that it may combine data supplied 
15 from the client or customer site with data drawn from distributed data bases 
in order to efficiently process orders or complete requests, or both. It is an 
advantage of this system that order processing and transaction completion 
is fast and efficient and the cable technician/client or customer receives 
immediate feedback concerning the order or transaction. 
20 Other objects, features, and advantages of the present invention will 

be apparent to persons of ordinary skill in the relevant art. 
BRIEF DFSrR IPTTQN OF TH E PR A WTMng 

For a more complete understanding of the present invention and the 
advantages thereof, reference is now made to the following description taken 
25 in conjunction with the drawings, wherein like reference numerals represent 
like parts. 

Fig. l is a block diagram depicting an embodiment of an overall 
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system architecture. 

Fig. 2 is a block diagram depicting an embodiment of a regional 
office system. 

Fig. 3 is a block diagram depicting an embodiment of a node 
processor connected to the wide area network of Fig. 1. 

Fig. 4 is a block diagram of an overview of a client or customer-site 
order processing system of the present invention. 

Fig. 5(a) is a block diagram depicting of the interfaces of the present 
invention. 

Fig. 5(b) is a context diagram indicating the general dataflow of a 
client or customer-site order processing system of the present invention. 

Fig. 6 is a diagram providing an example of records stored within the 
system of the present invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

An overall system architecture suitable for use with various 
embodiments of the present invention is depicted in Fig. 1. System 10 in 
Fig. 1 comprises a host system 12, hierarchical systems 30, and supporting 
systems 32. Hierarchical systems 30 may comprise a plurality of regional 
office systems 14, a plurality of divisional office systems 16, a plurality of 
state office systems 18, and a plurality of franchise systems 20 distributed 
over a wide area network (WAN) 100. Each franchise system 20 may 
control the operations of a single cable television provider or a plurality of 
cable television providers. If a plurality of cable television providers are 
controlled, then each cable television provider in this preferred embodiment 
has a node system 28 associated with the cable television provider. Support 
systems 32 may comprise a bill printing system 22, a bill payment system 
24, and an accounting system 26 distributed on WAN 100. 
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System 10 depicts an architecture in which at least six hierarchical 
levels exist. For example, the hierarchical order may be host system 12, 
regional office systems 14 (see Fig. 2), divisional office systems 16, state 
offices 18, franchise systems 20, and nodes 28. System 10 may also 
comprise additional systems distributed on WAN 100. Moreover, systems 
with additional or fewer hierarchical levels also are possible. 

Host system 12 may have hierarchical control over each subsystem 
of hierarchical system 30, each subsystem of support system 32, and any 
other system distributed on WAN 100. As such, centralized control of every 
system on the network may be achieved. Within hierarchical control system 
30, control may be exercised according to a hierarchy. For example, each 
regional office system 14 may control certain operations of the divisional 
office systems 16, which have been assigned to it. Similarly, each divisional 
office system 16 may control certain operations of each of the state office 
systems 18, which have been assigned to it. Further, each state office system 
18 may control certain operations of each franchise system 20, which it has 
been assigned. Further, if franchise system 20 has more than one associated 
cable television provider, franchise system 20 may control certain operations 
of each node system 28 assigned to each of those cable television providers. 
For example, each node system 28 may be assigned to one and only one 
franchise system 20, each franchise system 20 may be assigned to one and 
only one state office system 18, each state office system 1 8 may be assigned 
to one and only one divisional office system 16, each divisional office 
system 16 may be assigned to one and only one regional office system 14, 
and each regional office system 14 may be under the direct control of hosr 
system 12. 

Although regional office systems 14, divisional office systems 16, and 
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state office systems 1 8 may have different functions as described below, 
their system architecture may be essentially similar. Fig. 2 depicts a system 
architecture for a regional office system 14 in greater detail. Regional office 
system 14 comprises a main regional processor 40 connected to WAN 100 
5 and a plurality of customer service processors 42 in communication with 
regional processor 40. Thus, the architecture for divisional office system 16 
and state office system 1 8 may be similar, each having a main processor 
connected to WAN 100 and a plurality of customer service processors in 
communication therewith. 
10 Fig. 3 depicts the system architecture of a node system 28. Node 

system 28 comprises a node processor 50 connected to WAN 100. Further, 
node processor 50 may comprise one or more sub-processors. For example, 
node processor 50 may comprise a technician control sub-processor 52 and 
an administration sub-processor 54. Technician control sub-processor 52 
1 5 may be in communication with one or more technicians, who may be called 
upon to respond to transactions (e^g,, service requests) at one of a plurality 
service locations assigned to node processor 50. Administration sub- 
processor 54 may control internal operations of node 28, for example. Node 
processor 50 may also be in communication with a plurality of customer 
20 service processors 56. 

In addition, node processor 50 may be connected to a head end unit 
58 and its associated head end controller 62. Head end controller 62 may 
also be connected directly to WAN 100. Head end 58 may also be 
connected to one or more satellite receivers 60 according to known 
25 techniques in the art. Head end 58 may further be connected to at least one 
television 74 at least one service location 64. The connection between head 
end 58 may be by coaxial cable, fiber optic cable, telephone lines, and the 
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like. 

Node processor 50 may also be connected to an automatic response 
unit (ARU) 70. ARU 70 is connected to incoming telephone lines 68 and 
operates to identify incoming callers to more quickly direct their calls. 
5 Telephones 72 at service locations 64 may be connected to telephone lines 
68 and, thus, to ARU 70. Details of ARU operations are provided below. 

Franchise system 20 may either resemble regional office system 14 
or node system 28. Moreover, franchise systems 20 may be associated with 
one or many node systems 28. If only one node is present, franchise system 
10 20 is a node system and, thus, may be similar to node system 28 as depicted 
in Fig. 3. If more than one node system 28 is associated with a particular 
franchise system 20, franchise system 20 may resemble regional system 14. 

Referring to Fig. 4, an overview of an "In-Home" Order Processing 
System (MOPS) 200 of the present invention is depicted. Operation of the 
1 5 system may be initiated by a CSR visiting the home or business of a present 
or potential cable subscriber (e^, the client). The visit may be prompted, 
for example, by the initial installation of cable service, the correction of a 
service problem, or a service or equipment upgrade. The customer may 
request a particular product or package of products, or the CSR may offer 
20 the customer a short time or one-program promotion to sample a particular 
product or package of products. 

In explaining the present invention and its objects and advantages, a 
general understanding of terminology is provided below. 

A cable television provider is generally any entity which has 
25 a franchise to provide cable television programming. 

A client is generally the person or legal entity (an individual 
or a company) that is financially responsible for programming and other 
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services purchased from, a cable television provider. For example, the client 
may be Joe Smith or ABC, Inc. 

A service location (or client or customer-site) is generally the 
physical site (a house, apartment, or business office, and the like) at which 
5 a cable television provider provides, or may provide, programming and other 
services. For example, the service location may be 123 Main Street, 
Hometown, New York. 

A product is generally a good or service provided by the cable 
television provider to the client. For example, the product may be Home 
1 0 Box Office® or installation. 

A product parameter is generally any parameter which defines 
the product. Product parameters may include product name, product 
availability, product pricing, product start and stop time/date, and the like. 
The individual products described above may be grouped based on 
1 5 the type of service and the way in which each is marketed to the subscriber. 
The following groupings are terms used by cable television system personnel 
in the definition of products. 

Standalone Products - Standalone products represent a low 
level of product definition and include non-package one-time and recurring 
20 charge products. Standalone products are sold to subscribers separately, but 
may be bundled with other standalone products to create a package or 
promotion. Examples of standalone products may include: equipment rental, 
installation, and basic cable packages. 

Premium Products - Premium products are optional 

25 entertainment services that are offered as a standalone product or in a 
product package or promotion. Examples of premium products may include 
HBO®, Cinemax®, Showtime®, TMC®, the Disney Channel®, Starz®, and 
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25 



Ala-Carte Products - Ala-Carte products are a network service 
that may be included in a basic or expanded basic product, but which has 
been removed and is sold separately due to contractual restrictions. Ala- 
Carte products may be bundled with other Ala-Carte products and 
standalone products to create a package. Examples of Ala-Carte products 
include: BET*, TNT*, ESPN*, TBS*, and AMC* 

As noted above, these products may be sub-grouped into packages. 
This narrows the definition of the product based on the selected package 
which are then presented to the client. For example, a list of such packages 
may include: premium, basic, expanded basic, and pay-per-view (PPV) 
movies md s P ortm 8 event S Premium products have generally been 
described above. A Basic product may include local off-air programming, 
such as local VHF and UHF channels that are offered in the subscriber's 
area; Local Access programming, such as channel slots that are provided for 
local government and local programming; and Congressional access 
prograrnming, such as C-SPAN 1 & 2* Often, cable television providers are 
required to cany local and Congressional access channels as a matter of law. 
An expanded basic package is essentially a Basic package which has to be 
tailored to meet particular customer desires by the addition of selected ala- 
carte products. 

A product transaction, such as a package order, may be initiated by 
a cable technician entering data describing the customer, the 
product/package, its start and stop times, and the type of equipment at the 
customer's site on a portable transmitter or transceiver 210, e^, a Telxon* 
transmitter. All of the necessary information to initiate the product package 
service may be entered by the cable technician. This information may be 
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input alpha-numerical ly using a keyboard, by activating sites on a screen 
display with a light-pen, or by selecting icons with a mouse, or by similar 
means. For example, the transmitter/transceiver 210 may utilize a menu 
screen or display identifying various categories and employing pull-down 
5 bars to enter information. In any event, the method of and means for 
inputting data may vary with the structure of transmitter or transceiver 210. 
Alternatively, some or most of the necessary data to initiate service may be 
stored in and retrieved from databases accessible through the system. 

Referring again to Fig. 4, an "In-Home" Processing System (IHOPS) 
10 200 may include four basic elements. First, a combination of apparatus, 
such as transmitters, receivers, and modems, and means of data transmission, 
such as coaxial cable and telephone lines, which receive the transaction in 
the customer's home or at his or her place of business and relay it to the 
second basic element the dispatcher. The dispatcher may comprise various 
1 5 components to process the transaction and convert it into a message form at 
readable by the other basic elements of the IHOPS. In a particular 
embodiment, the dispatcher may comprise a queue, such as a persistent 
queue, in order to store the transactions as they are received by the 
dispatcher. The third basic element of the IHOPS may include three 
20 modules: the dispatch module, the data delivery server module, and the 
addressability module, for processing transactions relayed by the dispatcher. 
The dispatch module receives the transaction message from the dispatcher 
and passes it to the data delivery server module. From the data delivery 
server module, the transaction is returned to the data utility server portion of 
25 the dispatch module, so that data needed to complete the implementation of 
the transaction may be extracted, and the transaction message, enhanced 
with the extracted data, then is returned to the data delivery server. The data 
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delivery server then transmits the enhanced transaction message to the 
addressibihty module. The addressibihty module determines the appropriate 
controller for accomplishing the transaction, and formulates a transaction 
message for transmission to the fourth basic element of the IHOPS This 
i fourth element may include the controller .dentified by the addressibihty 
module; a converter box, if appropriate; and a tension or television 
monitor. 

Portable transmitter or transceiver 2 1 0 may send the initiating data via 
RF signal 212 to a relay transmitter or transceiver 214. Transmitter or 
transceiver 214 may be located in the cable technician's vehicle or it may be 
more permanently positioned at a location within range of a group of cable 
technicians serving all of the cable television subscribers within a geographic 
area. RF relay signal 216 is sent by relay transmitter/transceiver 214 to a 
modem 218, which converts relay signal 216 to a machine readable form 
compatible with the other elements of the IHOPS 200, and transmits the 
initiating data via standard computer cable 220, such as RS-232 to 
dispatcher 230. Moreover, the vanous components and connections between 
transmitter or transceiver 210 and d 1S patcher 230 may be replaced with a 
pager. 

Dispatcher 230 processes the initiating data, identifies its source, and 
formats it for further processing within the IHOPS 200. Dispatcher 230 is 
a means for (1) tracking the location, e^, by use of a Global Positioning 
System (GPS), of the technician; (2) automatic routing of orders generated 
by the technician to the appropriate node, franchise, or the like, for example 
based on algorithmic parameters; and (3) maintaining at least one queue' 
Thus, dispatcher 230 places the initiating data message in a queue, for 
example, in a persistent queue 232. to allow system 200 to process the data 
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in the order in which it is received and to allow the message to be retrieved 
from the queue at anytime by the IHOPS. Further, persistent queue 232 
all ows information to be recovered from the queue despite interruptions in 
system continuity, for example, due to power losses. In an embodiment, the 
5 functions of dispatcher 230 may be performed by FLEETCON™ dispatch 
system software, which is made available commercially by Arrowsmith 
Technologies, Inc. of Austin, Texas. 

A message 234 is retrieved from persistent queue 232 to a Client 
Message Server (CMS) 242. CMS 242 is located within a dispatch module 

1 0 240 and transmits the information of message 234 to a Data Directory Server 
(DDS) 250 in a DDS module 250*. Message 234 is relayed from dispatcher 
230 to CMS 242 in dispatch module 240 by means of a socket-to-socket 
connection; for example, by a Transmit Control Protocol/Internet Protocol 
(TCP/IP). However, in the embodiment of Fig. 4, there is no SYBASE® 

15 interaction between dispatcher 230 and dispatch module 240. The 
information sent from CMS 242 is contained in a message 244 which may 
be a Remote Procedure Call (RPC). DDS 250 manages the routing of all 
mcorning CMS messages to an available Dispatch Utility Server (DUS) 246. 
DUS 246 is located within dispatch module 240, and available DUS 246 is 

20 identified by DDS 250 according to a set of preconfigured rules. 

DUS 246 accepts a message 252 from DDS 250 and extracts 
additional equipment and product/package information from associated 
databases (not shown), which is necessary to perform the addressability 
transaction and complete the transaction processing. Once the additional 

25 information has been extracted, DUS 246 transmits a message to an 
Addressability module 260 via DDS 250. For example, DUS 246 may 
transmit a message 248, e^, an Addressability Change Services RPC, to be 
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relayed as a message 254 via DDS 250. 

An Addressability Open Server 262 accepts message 254 e^ the 
Addressability Change Services RPC, sent via DDS 250 and exacts the 
pertinent controller information from the message in an Addressability 
5 Manager Server 264. Once the controller has been identified, e^, TAC 
Jerrold, SA, Tocom, or Zenith, an appropriate message 268 is formulated in 
the portion of Addressability module 260 associated with the identified 
controUer, such as controller server 266. Message 268 is sent to a Controller 
270 from which it is relayed to a television or television monitor 290 located 
10 ,n the subscriber's home or business via an installed cable convenor or 
separate convenor box 280. 

Fig. 5a further illustrates the system and architecture of one 
embodiment of the present invention. The invention is described in 
connection with an "In-Home" Order Processing System (IHOPS) 300 
having a distributed database. Such system is useful for, among other things 
for rapid enabling or disabling of cable tension products/packages' 
However, the invention is not limited to this use. Examples of other uses 
include telephone equipment and computer on-line services authorization, 
alarm system monitoring services, and the like. As shown in Fig. 5a, the 
20 IHOPS 300 may comprise a plurality of transaction generators 305 e^ 
customer representatives labeled C, through C N , where N equals an integer 
Each transaction generator 305 is connected via a remote communication 
Imk 3 10 with a dispatcher 315. D.spatcher 3 1 5 stores database transactions 
transmitted over link 3 1 0 in a pers.stent queue before former transnutting 
25 them to a Client Message Server (CMS) 320. The database. transaction 
transmitted over link 3 10 may take the form of a Box Hit Request RPC and 
the actual message may comprise the following: 



15 



BN8DOCI0: •dMO_J72«7»»1 JL> 



WO 97/24879 




PCT/US96/20132 



21 

Box Hit Request 

Fulfillment Center ID 
Work Order Number 
Converter Serial Number 
5 Converter Type 

Message Type. 

Because this database transaction is placed In a persistent queue, the 
message may be retrieved at anytime. Nevertheless, an embodiment may 
allow the message to be read immediately as supplied. 

10 The database transaction may then be transmitted from CMS 325 via 

data links 330 to one (or more) data directory servers (DDS) 335. The 
present invention may include one or more DDSs 335. Each DDS 335 in 
turn is connected via a two-way communication link 340 to multiple dispatch 
utility servers (DUS, N , where N equals an integer) 345. 

15 As noted above, CMS 325 accepts the Box Hit Request RPC from 

dispatcher 3 15. CMS 325 then transmits a new message, which also may be 

in the form of a RPC, e^, an rp-AddrMessage, to DDS 335 for further 

transmission to DUS 345. The message may comprise the following: 

rp-AddrMessage 
20 Fulfillment Center ID 

Work Order Number 
Converter Serial Number 
Converter Type 
Message Type. 

25 Each DUS 345 is in turn connected to one or more databases 355 either as 
components of a single subsystem (processor and database) or through a 
two-way communication link 350. Additionally, each DDS 335 is connected 
via a two-way communication link 360 to one or more cross reference 
servers (XREFi N , where N equals an integer) 365. 

30 F >g- 5a indicates a DDS module 335 ! comprising DDS, N 325, 



BNBDOCID: <WO_8724fl7QA1 JU> 



WO 97/24879 




PCT/US96/20132 



22 

where N equals an integer, representing DDS functionality within IHOPS 
300. It is to be understood that although not shown in Fig. 5a, connections 
between transaction generators 305 and DDSs 335 as well as those between 
data servers 345 and DDSs 335 are preferably individual connections rather 
5 than to a grouping of DDSs such as DDS module 335'. For example 
transaction generator C, may be separately connected to each of the DDSs 
Alternatively, however, DDS functionality may be grouped with common 
connections to transaction generators 305 and/or DUSs 345, as indicated in 
Fig. 5a, so long as control between DDSs 335 is maintained. 
10 Additionally, IHOPS 300 includes at least one control application 375 

for communication between the DDS(s) 335 and a human operator and/or 
another IHOPS process. As will be discussed in more detail below, the 
control application 375 provides, among other functionality, a means for 
updating the internal rules used by the DDSs 335 to identify the available 
15 DUS 345. As described in more detail below, when a transaction is 
generated by a transaction generator 305 and sent to a data directory server 
335, the data directory server 335 determines the appropriate DUS 345 for 
execution of the transaction. Preferably, thus is accomplished by the DDS 
335 consulting the internal rules and identifying the arguments associated 
20 with the transaction, as detailed below. 

IHOPS 300 of the present invention is designed to manage a very 
large number of transactions occurring within the system. IHOPS 300 of the 
present invention provides the ability to query across the entire database 
from any subscriber in the system. Similarly, each of the users may update 
25 data located anywhere within IHOPS 300 

Client - Tr ansaction Generator 
The transaction generators 305 in the system of the present invention 
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may be any devices capable of receiving input from a user and transmitting 
that input to DDSs 335. This type of device is often referred to as a "Client" 
and these terms are used interchangeably herein. These devices may be 
dumb terminals (Le,, incapable of performing local processing) or they may 
5 have various processing capabilities of their own. Examples of transaction 
generators include, without limitation, Telxon transmitters; Personal 
Computers, such as laptops; and the like. In typical applications, there will 
be a plurality of transaction generators 305, such as one for each cable 
television technician or CSR. Thus, IHOPS 300 is designed as an open 
10 platform environment which is hardware independent. The transaction 
generators 305 may be homogeneous in terms of interface and operation or 
they may be heterogeneous. In other words, all transaction generators 305 
may be of one type or there may be a variety of devices interacting with the 
DDSs 335. It is also possible to permit Client interaction with IHOPS 300 
15 through an ARU/ANI (Automated Interactive Voice Response 
Unit/ Automatic Number Indicator) (not shown). In this case, much of the 
processing may be driven by the telephone number retrieved by the ANI 
when the subscriber calls into the system. 

Data Delivery Server 
20 The DDSs 335 of the present invention function as the middle tier of 

a three tier system architecture. As illustrated in Fig. 5a, more than one 
DDS 335 may exist within IHOPS 300. In such case, each of the DDSs 335 
has communication access to all of the other DDSs 335 as well as to each of 
DUS 345. DDSs 335 serve three primary functions. After receiving a 
25 transaction, the selected DDS 335 first locates the appropriate/available DUS 
345 for the further processing of the transaction, it then submits the 
transaction to the DDS 335 which forwards it to the Addressability module 
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260. 



Transact,™ generators 305 requesting information from the IHOPS 
databases must connect to a DDS 335 prior to accessmg data. Through the 
use of mtemal ralcs , me DDSs 335 de(enmne hw a remoK 

5 shouid nm in order to c„mp,e,e processing of a transaction. Forexamp.e 
these interna! ndes may be provided diredy from a conlrol ^ 

v,a connections 370 or indirectly via X-Ref Servers 365. These operations 
are d.scussed in greater detai, be.ow. Access to the DDSs 335 may be 
effic.en.ly implemented through the use of remote procedure calls (RPCs) 
10 which are identified in tables internal to the DDS 335. Any of a plural.ty of 
standards for such RPCs may be used with the current invention 

The DDS(s) 335 are preferably open server applications ma, provide 
a mechanism to direct any data request associated with a generated 
transaction to DUS 345 available to service the transaction generator's 
1 5 requests. Specifically, DDSs 335 may be open servers comprising the same 
or smular hardware as DUS 345 of the present invention. Alternatively 
DDSs 335 may be configured differently from DUS 345 DDSs 335 
function to analyze the clienfs traction and, based upon the transaction 

DUS 345. The types of transactions which are received a, DDSs 335 are 
based upon a se, of stored procedures recogmzable to DDSs 335 and 
available to the transaction generators 305. 

Prior to discussing the specifics of database transactions according to 

DDSs 335 preferably operate according to a limited number of even, 
handlers responsible for processing the transactions genera,ed by the 
taction generators 305, as we,, as interna, requests generated as a result 



BNSOOCID: <WO_9724S78A1JU> 



WO 97/24879 




PO7US96/20132 



25 

of DDS processing itself. For example, the event handlers may include, but 
are not limited to, the following: 

1 Start Handler - The start handler provides a convenient and 
central location for installing any other event handler routines, building any 
5 tables necessary for processing Client requests and for installing any other 
services that the DDS requires for its functionality. 

2. Stop Handler - The stop handler is executed when a request 
to shut down the system has been received through a particular request or as 
a result of certain system conditions. 
10 3. Connect Handler - The connect handler is executed whenever 

a Client connects to the DDS. 

4. Disconnec t Handler - The disconnect handler is executed 
whenever a Client terminates an active connection to the DDS. 

5 Language Handler - The language handler is executed 
1 5 whenever a Client application issues a language statement to the DDS. The 
language handler in the DDS does nothing because all Client requests are 
required to be either registered procedure calls or remote procedure calls. 

6. RPC Handler - The Remote Procedure Call handler carries the 
bulk of the load borne by the DDS and is the most important handler for 
20 purposes of this discussion. Any Client transaction which is not registered 
in the DDS registered procedure table will generate an RPC handler event 
where the request is analyzed by the RPC event handler and acted upon 
accordingly. 

7 Error Handlers - Several error handlers are installed in the 
25 DDS application to provide information on any failure from the Client or the 

components of the DDS. All error messages are logged in the DDS. 

8 Attention Handlers - An attention handler is installed to 
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handle disconnects from a Client. The DDS has been set up to cause all 
Client disconnects to generate an attention event in order to determine if the 
Client has interrupted its connection to the DDS. 

The functionality comprising the operation of the DDS may be 
5 categorized into three separate classes - the main function, the local DDS 
registered procedures and the utility functions. The main function provides 
the entry point for all executable C programs. Although the preferred 
embodiment is formulated using the C and C++ languages, the invention 
described herein is by no means limited to such a design. The error handlers 
10 and the start handler are installed in the main function body. These include 
a set of routines which serve to parse input parameters and configuration file 
attributes in order to set up any DDS properties. The network listening 
function is spawned in the main function body and sleeps until the DDS 
application is terminated either normally or abnormally. 
15 The DDS application is dependent on several global data tables. 

These global tables are used to control the navigational decisions that the 
RPC Handler needs to direct the Client's transactions to the appropriate data 
server in order to complete the data request. A more detailed discussion of 
the global tables, including construction, maintenance, and use, follows 
20 below. 

The Open Server Install Registered Procedures, os_install_reg_procs 
( ), function provides a central installation point for all registered procedures 
on the DDS and is grouped in the start handler classification. Service 
requests originating at the Client that are not identified as a registered 
25 procedure, are treated as remote procedure calls and are handled by the RPC 
Handler. All of the event handlers and supporting system functions provide 
a trace log of activities in a locally maintained log file. This file is 
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preferably truncated every time the DDS application is started. 

Dispatch Utility Servers 
The DUSs 345 maintain customer data and are accessible by each of 
the transaction generators 305 through a DDS 335. In a typical 
5 implementation, the dispatch utility servers are SQL devices which are 
capable of executing the RPCs transmitted by a DDS 335. Databases 355 
( F !...n* F'i...n> F"r...N> - • •> where N equals an integer), which support DUS 
345, may be either homogenous or heterogeneous. 

The customer records in Fig. 6 contain various information about the 
10 customer and his, her, or its account. In a typical implementation, there 
would be much more data. In the example, the first item listed is a customer 
number. In the preferred embodiment, each customer record corresponds to 
a unique customer number. Next, the customer name is listed followed by 
the customer's birth date. Also included is the customer's telephone 
1 5 number, the services subscribed to, and any recent pay-per-view activity as 
well as the associated cost. Finally, a code for the cable operator location 
for the subscriber is included. 

In a homogeneous environment, particular protocols for accessing 
each of the databases are consistent throughout the hierarchy. Conversely, 
20 in a heterogeneous environment, the particulars of database access may vary 
within the server. In a heterogeneous environment, it is often desirable, 
however, to render any differences in requirements within the enterprise 
transparent to a cable technician or CSR at the client site. Thus, a cable 
technician or CSR ideally is not aware of any database heterogeneity, and 
25 a transaction preferably is processed in a standard manner across all 
resources. 

Databases 355, which are accessed in a distributed system, may all 
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be located together or they may be physically apart. They may be at the 
client location or they may be at an alternate site. Databases 355 may be 
relational databases, such as SYBASE® databases (a trademarked product of 
Sybase, Inc.), or they may be as simple as a series of flat files. DUS 345 
accepting the rp_AddMessage RPC from DDS 335 extracts additional 
equipment and product information from databases 355, which is needed to 
perform the Addressability portion of the transaction. 

Control App lication 
Returning to Fig. 5a, it can be seen that the DDSs 335 may interface 
with a control application 375. The control application 375 functions to 
allow a system operator to store, update, and modify stored procedures 
available to all transaction generators 305. This is typically accomplished 
by downloading the update to the X-Ref Server 365 which loads a rules 
database into DDSs 335 at DDS startup. 

X-Ref Servers 

An IHOP System also may include one or more X-Ref Servers 365 
which function as a resource available to DDSs 335 for detennining where 
specific data resides in the system and for storing a rules database to be 
loaded into DDSs 335 at DDS start-up. Further, the X-Ref Servers 365 may 
contain a variety of global tables which are continually updated as data is 
added, updated, and deleted within the system. 

Addressability Module 

Finally, Fig. 5a depicts an Addressability module 385. As noted 
above, after DUS 345 extracts the additional equipment and product 
information from databases 355, it formulates an Addressability Change 
Services RPC. This RPC is transmitted to Addressability module 385 via 
two-way communication link 340, DDS 335, and communication link 380. 
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The RPC may comprise the following format: 

Change Services 

Converter Equipment ID 
HUB ID 

5 Hotel Indicator 

Add Service Code 
Delete Service Code 

Addressability module 385 accepts this Change Services RPC and 

extracts the pertinent controller information from the message. 

10 Addressability module 385 then identifies the appropriate controller (CNTR, 

• • . n» where N is an integer) 395, calls Controller 395 via communication link 

390, and instructs it to enable or disable service at equipment site 405. For 

example, although the RPC will differ for each controller, the RPC for a 

TAC controller may comprise the following: 

1 5 Hit Equip Parameter 

Equipment Serial Number 
Equipment Type 
Parameter 
Value 

20 Turning now to Fig. 5b, a context diagram and flow chart, 

respectively for the IHOPS 300 as controlled and regulated by DDS 335 are 
provided. In a preferred embodiment, the DDSs 335 access the XRef 
Server(s) 365 at startup to access database information employed for the 
operation of DDSs 335. After the start-up tasks are complete, client 

15 transactions may be processed by DDSs 335. Alternatively, the DDSs 335 
may access the XRef Server(s) 365 (or any other system component 
containing the desired data, e^, DUSs 345) as transactions are received by 
DDSs 335. 

For example, Client product orders are initiated at the transaction 
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generators 305 and transmitted to a DDS 335 via Dispatcher 3 15 and CMS 
325. Once it has received the data request, the DDS application consults the 
DDS Server Table (a global table) which identifies all of the ava.lable and 
accessible data servers, including DUSs 345. There is also provided an 
5 XRef Server Table (global) which identifies all known and accessible XRef 
Servers 365. An additional globaJ table is the Error Message Handler Table 
which maintains all error handler messages. All of the global tables defined 
in DDS 335 provide feature functionality to support the access related to 
these tables. 

' 0 Fig. 5b depicts a context diagram of the system and also shows the 

various transaction generators 305 connected to DDS 335. Transaction 
generators 305 make requests for product/package enablement and 
disablement through DDS 335. As discussed above, once such a request is 
received, DDS 335 may determine the set of available DUSs 345 which may 
15 execute the request and selects one or more servers from that set for 
servicing. The subset of servers which are available to process the request 
may be determined in the manner discussed above. In a first embodiment 
global tables are loaded from the XRef Server 365 into an internal DDS 
memory at DDS startup. In a second embodiment, no such loading occurs 
20 at startup - rather, upon receiving a product order, DDS 335 submits a 
request to the DUSs 345 in order to retrieve the necessary data. In e lt her 
embodiment, DDS 335 has available to it the rules database and other data 
which is required to determine the type of transaction (mcluding the data 
required and the locations of that data) and to select an available DUS 345 
25 for processing the transaction. After processing the request, DUSs 345 
return a message containing the processing results to the DDS 335 which 
then transmits the order to the addressability server 385. Confirmation of the 
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order processing then may be sent back to transaction generator 305. 

After a product order has been processed and confirmation returned 
to the transaction generator 305, DDS 335 may receive another transaction 
and process it in accordance with the above procedure. In such an 
5 embodiment, DDS 335 does not begin processing a new order until it has 
completed processing of the prior order. In another and a preferred 
embodiment, a single DDS 335 processes multiple product orders 
concurrently exploiting the availability of numerous DUSs 345 and 
Addressability servers 385 for processing a plurality of transactions 
10 simultaneously. 

As mentioned above, the DDS 335 maintains several global tables 
which are constructed and supported by classes. These tables inform the 
system of where data resides and where it is to be routed, as well as methods 
for locating and routing such data. The first class to be discussed is the 

15 Server Table Class. The Server Table Class is a global class. This class 
references all available servers in the IHOPS 300. The Server Table class 
supports two tables that are constructed from DDS data files. The first table, 
the DDS Server Table, identifies all available data servers, including DUSs 
345, that are accessible by DDS 335. The second table supported by the 

20 Server Table Class is the XRef Server Table, which refers to all available 
XRef Servers. Both of the Server Tables provide server names, logins, and 
password information to DDS 335, so that it may access any DUS 345 
within IHOPS 300. 

The Server Table class employs information structure pointers to 
25 support the list of available servers specified by the class instantiation. The 
class provides methods to randomly retrieve the next available server in the 
table or to select a specific server in the table. In addition, it is possible to 
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remeve the user ID and password assoc.ated with a server as well as the 

number of servers available. 

The XRef Server Table ,s bui.t on the instantiation of the Server 
Table Object through the applicable DOS data file. The Server Tables are 
bu,l, based on the server names, and in a preferred embodiment, the initial 
ordenng may be alphabetical by server name 

The DOS Server Table is a global table which ,s also constructed 
from the DDS data file. The Server Table Cass definition of a preferred 
embodiment is given below: 



10 class ServerTbl 
{ 

private: 

Srvlnfo 
CS_INT 
15 CS_INT 
protected: 



20 



25 



public: 



} 



CS_CHAR 

CS_CHAR 

CSCHAR 

CS_INT 

CSCHAR 

CS VOID 



*_server; 

_next; 

_serverCnt; 

ServerTbl(); 



//server information structure 
//next server name 
//server count 



ServerTbl(CS_CHAR*,constCS CHAR*) 
~ServerTbl(); ~ 

*GetNext(); 

*GetUID(); //mJm 

? r et ?f 0; . r //inline 
*GetSpecific(CS_INT I); //inline 

UpdateTbl(CS_CHAR*,const CS_CHAR*); 



Th,s definition identifies the server information structure the next 
avatlable server, and the number of servers of. specified type It is to be 
30 understood that the Cass definition il.ustrated above 1S given by way of 
example only and is not the only possible class definition which may be 
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employed in the present invention. 

The ServerTbl class definition includes the server information 
structure pointer which supports a list of available servers specified by the 
class instantiation and contains the server name, a user ID, and a password. 
5 The user ID and password are available for use with any system 
administration functionality that supports the DDS server. The next data 
member is an integer value that contains the next element of the server list 
(the next available server). It is possible to access this information through 
a calling routine discussed below. Finally, the _serverCnt element is 

10 included. This member also is an integer value containing the number of 
servers available to the calling routine. 

The Server Table class definition of the preferred embodiment also 
contains various member functions. The class constructor 
ServerTbl(CS_CHAR *, const CS_CHAR *) takes as arguments the type of 

1 5 server (XRef, DUS, or DDS) and the server data table name. When called, 
this constructor initializes the member data and calls the UpdateTbl function 
with the same arguments. As a result, the server table may be initialized and 
built. 

The UpdateTbl function performs all of the DDS data file 
20 management to obtain the required information concerning a specified 
server. In addition, this function serves to build the Server Table. The 
GetNext function returns the next available server in the instantiated table. 
This function provides a level of randomization to evenly distribute server 
request loads. The GetUID function returns the current user ID for the 
>5 specified server. The GetPswd function returns the current user password 
for the specified server. The GetCnt function returns the current number of 
servers of the instantiated type. Finally, the GetSpecific function returns a 
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specifically requested server table entry. 

The next class to be d.scussed is the Server Name class. Again 
vanous functions may be assodated with flu, class, for example, to allow 
the DOS to select a stored procedure. The server name is represented by this 
5 class definition which identifies the current server table element and the 
procedure element requesting the server name. The Server Name class 
definition of a preferred embodiment is provided below, 
class SrvName 
{ 

1 0 private: 

ProcElem *_p- 
CSJNT arg Val; 
CS_INT _curElem; 

public: 



15 



SrvName(ProcElem*,CS_VOID**)- 
~SrvName(); 

SrvElem *GetNext(SrvElem*&)- 
SryName& operator^(const SrvName&V 
CS_INT GetSrvCnt(); 



20 CS_rNT GetSrvTyp(); 



The Server Name class idendf.es the current server table element that 
suppom me current stored procedure in the procedure list, ta addition this 
class proves data elements that point to the current stored procedure in the 
procedure list table Finally, the class stores parameters associated with the 
current stored procedure and a current element flag. 

The _p data member is a pointer to the procedure list table stored in 
the DOS. The _argVal data member con tains an integer value that identifies 
the argument position for any rule based stored procedure. The curElem 
member is an integer which represents the currently selected procedure from 
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the procedure list. 

The GetNext( ) member function applies the rules for retrieving the 
appropriate server name. As will be discussed below, this is necessary when 
the DDS must process an "ANY" product order. The GetSrvCnt( ) simple 
5 returns the number of servers associated with the current stored procedure. 
The GetSrvTyp( ) returns the distributed transaction processing (DTP) code 
back to the requestor. As will be discussed below, the DTP code refers to 
a particular processing paradigms including ANY, ALL, and SPECIFIC. 

The class constructor and destructor functions allocate memory and 
10 construct the server table and deallocate and release the table respectively. 
An additional function provides a mechanism to return the name of the next 
server in the list. The member functions for the Server Name class are 
illustrated in Table 1. 

TABLE 1 

1 5 SERVER NAME CLASS FUNCTIONS 

* SrvName :: SrvName(ProcElem *_p, void **argList) 

Assign procedure element _p to SrvName class variable. 
If the argList a is not NULL 

Assign the argument position value to the class variable 
20 I initialize the current element class variable to 1 
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* SrvName :: GetNext( ) 

if (-P-> firstSrv) // GROUP 
if ((_p->dtpCode ==ALL) && 
(_curElem<=_p>elemCnt)) 

curSrv = _p->firstSrv[_curElem - 1 ] 
++_curElem 

else if (Cp ->dtpCode == ANY) && CcurElem = 1)) 
rNum = _p->firstSrv[GetRandom( )] 
++ curElem 

10 else if (Q, ->dtpCode == SPECIFIC) && CcurElem = l )) 

curSrv = _p->firstSrv[ curElem - 1 ] 
++_curElem 
else 

, . retrieval is complet, return a NULL pointer value 

n reset curElem to 1 

else if ( _p -> firsRule) 

for I = 0; K _p->firstCnt; I++ 
if argVal == NULL 
set curSrv to NULL 
20 . c ±e P^ameter for this stored procedure is missing 

if _argVal <= _p -> firstRulefi] -> high_val && 
_argVal >= _p -> fu- s tRule[i] -> lowVal && 
_curElem = I 

„ curSrv = _P->firstSrv[i].servers 

^ curSrv -> dbName = _p->dbName 

increment curElem 
break out of for loop 
else if curElem > 1 
set curSrv to NULL 
30 reset _curElem to 1 

break out of for loop 
else 

continue 
end for loop 
35 else 

set curSrv to NULL 

there is a problem with the XRef Data Tables 
return curSrv; 
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* SrvName :: GetSrvCnt( ) 
return _p->firstCnt 



♦SrvName :: GetSrvTyp( ) 
return p->dtp code 



The next group of classes to be discussed relate to the XRef Data 
tables. The XRef Data tables consist of database information that supports 
the decision making requirements to access the various data servers 
supporting the IHOPS application. Four tables located within the XRef 
10 Server contain information related to: 

• all of the stored procedures available for a client to submit to 
the DDS; 

all of the data servers accessible by the DDS; 
the various server groups that the data servers fall into; and 
15 • the rule boundary information that binds the rule based stored 

procedures to the data server(s) that can support the client 
request. 

This information is retrieved from the XRef Server by the DDS application 
at startup. The data is stored in at least three tables internally within the 
20 DDS. For example, the three internal tables may be: 

1) Procedure table - which consists of all stored procedures; 

2) Server table - which consists of all data server data; and 

3) Rule table - which consists of all decision rule data 

The data structures for these tables are constructed by stored procedures that 
25 return results in a format consistent with DDS internal storage format. Each 
of these tables is supported through the XRef class definition and is given 
below: 
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struct SrvElem 



15 



20 



25 



}; 



char SrvNamef MAXN AME] ; 

char warmSrv[MAXNAME];' 

char grpName[MAXNAME]'; 

int srvConn; 

int warm Conn; 



struct RuleElem 



10 { 



}; 



char 

int 

int 

char 

SrvElem 



ruleName[MAXNAME]; 
lowVal; 

highVal; 

srvName[MAXN AME] ; 



'servers 



30 }; 



struct ProcElem 
{ 

char 
char 
char 
char 
char 

PROCTYPE 

DTPCODE 

int 

int 

SrvElem 
RuleElem 



procName[MAXNAME]; 
grpNamefMAXNAME]; 

ruleName[MAXN AME] ; 

srvNamef MAXNAME]; ' 

dbName[MAXN AME] ; 
pType; 
dtp; 

argPos; 

firstCnt; 

♦firstSrv; 

*firstRule; 



35 



The XRef Data tables are represented by a class that defines data 
structures for the stored procedure list, the server list and the rules list. A 
count is also maintained for each of the lists. The XRef Data table class of 
a preferred embodiment is given next: 
class XRefDataTbl 
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* jirocList; 
*_srvList; 
*_ruleList; 
j>rocCnt; 

srvCnt; 

ruleCnt; 



{ 

private: 

ProcElem 

SrvElem 

RuIeElem 

CSJNT 

CS_INT 

CSJNT 
protected: 

XRefDataTbl(); 

public: 

XRefDataTbl(); 
-XRefDataTbl(); 

CSJNT GetProcCnt(); 
CSJNT GetSrvCnt(); 
ProcElement *GetProcList(); 



//inline 
//inline 
//inline 



}; 



CS_RETCODE GetServer(CS_CHAR*,CS_VOID**,SrvName*) 
CS_RETCODE UpdateTbl(CS_CHAR*,CS_CHAR*,CS_CHAR*); 
CS_RETCODE RunRpc(CS_CONNECTION*,CS_CHAR* CS INT) 
CS_RETCODE BldListQ; 



The _procList member data is a pointer to the list of stored 
procedures stored in the XRef data tables within the DDS. The srvList 

25 member data is a pointer to the list of data servers stored in the XRef data 
tables within the DDS. The ruleList member data is a pointer to the list of 
rules stored in the XRef data tables. The _procCnt member data is an 
integer value containing the number of stored procedures stored in the 
_procList. The SrvCnt member data is an integer value containing the 

30 number of data servers stored in the srvList. Finally, the ruleCnt member 
is an integer value containing the number of rules stored in the _ruleList. 

The member functions include a class constructor and destructor for 
creating and releasing the lists. Further, the GetServer( ) member function 
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retrieves a server name based on the procedure name and its arguments 

As discussed above, the XRef data tables are constructed through the 
class instantiation and are linked together based on the procedure names and 
its type. The XRef Data Table constructor function calls the table update 
member function that initialized the table element counts. It also may call 
the update function to build the tables. The GetProcCnt( ), GetSrvCnt( ) 
and GetProcUst( ) member functions are inline functions that return the' 
number of stored procedures m the procedure list, the number of servers in 
the server list, and a pointer to the procedure list respectively. Table 2 
illustrates the member functions associated with the XRef Data Table class 
in a preferred embodiment. 

TABLE 2 

XREF DATA TABLE CLASS FUNCTIONS 



The object constructor may be as follows: 

XRefDataTbl::XRefDatatbl( ) 

™£° Cedure ' server > ™ d ™le counts to zero 
Sd)t (CS - CHAR +Scrver ' CS - CHAR CS_CHAR 
CS _ SUCCEED) 

exit out of the function 
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The UpdateTbl function represents the XRef data table update function 
that builds the XRef data tables from the XRef Server. 

XRefDataTbl::UpdateTbl(CS-CHAR *server, CS.CHAR *uid CS- 
CHAR *pswd); 

{ 

Set up the client interface to the XRef Server 

This is a standard client library interface set up 
Run the stored procedure "lp_get_srv-cnt" to retrieve the 
number of servers stored in the database. 

if it fails, there is a problem with the XRef Table Data 
Run the stored procedure "lp get rule cnt" to retrieve the 
number of rules stored in the database. 

if it fails, there is a problem with the XRef Table Data 
Run the stored procedure "lp_get_proc cnt" to retrieve the 
number of procedures stored in the database, 
if it fails, there is a problem with the XRef Table Data 
Allocate sufficient memory to store the number of rows for the 
server list. Run the stored procedure "lp get srv list" to retrieve 
the data from 

the SERVERJ3ROUP and SERVER tables. 
Allocate sufficient memory e to store the number of rows for the 
rule list Run the stored procedure "lp_get_rule_list" to retrieve, 
the data from the 
RULE-BOUNDARY and SERVER tables. 

Allocate sufficient memory to store the number of rows for the 
procedure list. 

Run the stored procedure "lp_getjproc_Iist" to retrieve the data 
from the PROCEDURE table. 

Integrate the lists by calling the BldList( ) function 

Exit and clean up the client application 

}; 
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The Build List function builds the lists, such that the three XRef data 
tables are interlinked to provide a quick access to the desired server 
name based on the stored procedure issued by a user. 

XRefDataTbl::BldList( ) 

For every row returned from "lp-get_ pro c_cnf link the structure 
if procList->pType = GROUP 

sequentially search srvList for srvList->grpName == 

procList->grpName 
store first srvList element in procList->firstSrv 
1 u as sign procList->firstRule = NULL 

initialize first count to zero 

sequentially search srvList and count the number of 

servers supporting the server group 
store the count of the number of server in 
lb procList->firstCnt 

else if procList->pType = RULE 
sequentially search ruleList for 

srvList->ruleName=procList->ruleName 
stor e fast ruleList element in procList->firstRule 
ZKi assign procList->firstSrv = NULL 

sequentially search ruleList and count the number of 

rules supporting the server group 
store the count of the number of rules in 
procList->firstCnt 

25 sequentially search server List for server name 

assign server pointer to server list element 
else // procList->pType = SPECIFIC 

sequentially search server list for server name 
30 assign firstSrv to the server list element 

assign NULL to firstRule 
assign 1 to firstCnt 
break out of for loop 

Jj ._ 
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The Run RPC function issues the command to the remote data 
server and processes the results. 

XRefDataTbl: :RunRpc(CS-CONNECTION 
♦conptr, CS_CHAR *cmd, CSINT cmdType) 

Allocate the command structure 
Initiate the command 
Send the command 

Process the results based on the command type 

This functionality is specific to the type of command issued 
Drop the command structure 



15 
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The get server function searches the stored procedure list for 
a particular stored procedure and creates a server name class 
object to point to the first server supporting that stored procedure. 

CSRETCODE 

XRefDataTbl::GetServer(char *procname, void **argList, 
SrvName *server) 

{ 

Perform a binary search of the procedure list for the current 
stored procedure if it fails to get an entry, 

return CS - FAIL; 
Create server name object server for the procName and argList 
Assign server name to return parameter 
Return CS SUCCEED; 

J 



The DDS requires the Xref Data Table and Server Table information 
to operate in the IHOPS environment. The tables are used to locate the 
30 appropriate data server(s) to satisfy a client's stored procedure request. 
Additional stored procedures may continuously be added to the client's 
application to facilitate new and enhanced features in the IHOPS 
environment. These new stored procedures are included in the Xref server 
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data table to complete the implementation of the features wmch, in turn, 
requires a reload for the DDS internal tables. Also, additional data servers 
and DDSs may be added to the rHOPS. New servers are added to the DDS 
data table as well as to the Xref server data table so as to include these 
servers in the DDS internal tables. 

The next class to be discussed is the ClntUsrData class. The 
ClntUsrData class is used as a means of encapsulating information needed 
by a Client service thread in the DDS open server application. This class 
may be constructed in the connection handler and may be pointed to by the 
user data for the Client's internal client thread control structure. The data is 
encapsulated within self-describing data objects including the data itself and 
the type or format of the representation of the information. In this way it is 
unnecessary to access the related class descriptors or class definitions to 
retrieve the required semantic iiuormation. Through encapsulation, the data 
may be retrieved easily within any of the handlers that a Client thread may 
enter. The ClntUsrData class of a preferred embodiment is. 
class ClntUserData 
{ 
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private: 

FMT CTL* _fmtCTL; 
Ucon* ucon; 

public: 

ClntUsrData(int numSrvs, 

LoginData & loginData, 
CmdConPool *cmdConPoolPtrV 

~ClntUsrData(); 
virtual Ucon* GetUcony; / /inIme 

virtual FMT_CTL*GetFmtCtl(); //inline ^ 

The ClntUsrData class provides a repository for information related 
to a Client's user data which is stored and reused with the Client's thread 
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properties. This class encapsulates format control information needed to 
process result sets in the "ALL" scenario and user connection objects that 
allow a Client to re-use remote server connections. There exists at least one 
ClntUsr Data class allocation for each client accessing the DDS. 
5 The fimtCtl member data variable contains encapsulated information 

employed by several functions when processing results for an "ALL" 
scenario in the DDS application. The ucon member data variable is a user 
connection object that allows a DDS Client to re-use its remote server 
connections, saving the overhead of continually re-opening connections. It 
10 is an object that abstracts and organizes Client connections. 

The ClntUsrData( ) only constructor uses its arguments to allocate the 
_ucon object. It also allocates and initializes a FMT CTL structure. The 
~ClntUsrData( ) destructor de-allocates ucon and fmtCtl which were 
allocated by the constructor. The GetFmtCtl( ) inline member function 

15 returns the private __ftntCtl data member and the GetUcon( ) inline member 
returns the private ucon data member. 

The TopRPCList class ranks the most used RPC's, calculating each 
RPC's average execution time and returning the name, number of executions, 
and the average execution time to the requester. This class is called from the 

20 rp_mon_rpc registered procedure and is invoked when the DDS Control 
Application submits a monitoring request. All of the processing for this 
class is invoked from the constructor; no other member functions need be 
called by the requrester. The inherited TopList member functions support 
the underlying ordering work. The TopRPCList class of a preferred 

25 embodiment is: 

class TopRPCList: public TopList 

protected: 
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virtual COMPARECD CompareFunc(void *) 
public: 

TopRPCList(SRV_PROC*srvProcPtr, 
5 ProcElement* rpcListPtr, 

CSINT rpcListSize, 
CSJNT topListSize); 
~TopRPCList() { } 

} » 

1 0 The protected virtual function CompareFunc(void * item) provides a 

complete definition for the pure virtual function declared by TopList. This 
function compares the item >cumNumRuns against the current - 
>cumNumRuns and returns a COMPARJE_CD. 

The TopRPCList (SRV_PROC * srvProcPtr, ProcElement * 

1 5 rpcListPtr, CS_INT rpcListSize, CSJNT topListSize) constructor builds a 
list of topListSize ranked by the frequency of executions of RPC's in the 
array pointed to by rpcListPtr. The RPC list is of size rpcListSize. The RPC 
list and its size are defined in the XrefDataTbl class for the DDS. Once this 
list is loaded, the member function steps through the list, returning results to 

20 the requester. Each row contains the rpcname, the number of executions, 
and the average execution time for the RPC. The average execution time is 
calculated by dividing the cumSeconds by the cumNumRuns as stored in the 
ProcElement in the XRefDataTbl. 

RPC Handler 

25 The DDS of the present invention processes a majority of Client 

transactions through the RPC Handler which is now discussed. The DDS 
accepts Client stored procedure requests and first investigates the resident 
registered procedure list table to locate the RPC in question. If the RPC is 
found in the table, the procedure is executed locally. If the RPC is not found 

>0 in the table, the DDS raises a RPC Handler event and relinquishes control 
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to the handler routine. 

The RPC Handler processes all Client stored procedure requests to 
determine which of the DUSs should service the request. The RPC Handler 
provides a semi-passthru capability for Client's transactions that require 
5 selection of specific servers that may support the Client's transactions. This 
results in a single result set from the specified server. The RPC Handler also 
supports stored procedure requests from Client applications that access 
several data servers at a time within the same group. This allows for 
multiple transactions to be processed simultaneously. 
10 In semi-passthru mode, the system parses the incoming client RPC 

command request and the RPC command results are passed thru the 
intermediate DDS direcdy to the Addressability. The incoming Client server 
requests are parsed to identify the request and any parameters associated 
with the transactions. The command request and its parameters are used to 
1 5 identify the appropriate data server to best service the transaction. 

Initially and upon a request for service from a Client, the user data 
(including username, password, etc.) regarding such Client is obtained. The 
DDS uses this information to set up a User Connection Object. 

The RPC command name is then retrieved from the data stream as are 
20 the number of RPC parameters associated with the RPC command, and the 
RPC parameters if they exist. The RPC Handler then causes the appropriate 
Server name(s) for the remote procedure call to be determined. This is 
generally accomplished by getting the next server element. At this point, in 
a preferred embodiment of the invention, the RPC Monitoring functionality 
25 is instantiated so that the control with respect to transaction servicing may 
be optimized. 

The DDS then determines if a connection to the selected server(s) 
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exists. If so, the request is submitted to that server. If no connection exists, 
one is established. 

If the request was an "ALL" request (ul, a read from or order to all 
data servers in the IHOP System) then the results from all data servers are 
5 received by the DDS as part of the RPC Handler process flow. Otherwise, 
for requests directed to single or a group of data servers, the results are 
transmitted to the Addressability server in passthru mode through the DDS. 

ALL. ANY SPECIFIC 
The present invention acts on various scenarios for efficiently 
10 allocating requests to data servers based upon the type of transaction 
involved. As will be discussed in further detail below, a "SPECIFIC" 
request corresponds to a Procedure Type = Server and an "ANY" or "ALL" 
request corresponds to a Procedure Type = Group. 

The "ANY" scenario will be discussed in detail now. It is to be 
1 5 understood that some or all of the steps next discussed may be omitted and 
additional steps may be added while still remaining within the spirit of the 
invention. Initially, the transaction generator will issue an RPC request to 
the DDS. At this point the DDS will raise an RPC event which ,s handled 
by the RPC Handler functionality of the DDS. Next, the RPC counter is 
incremented to indicate that an active RPC is present in the DDS. The user 
data corresponding to the client thread properties then is obtained, and the 
user connection information is established. 

Once me preliminary setup is accomplished, the RPC command and 
its arguments are retrieved from the client request data stream. The DDS 
then obtains the appropriate data server information based upon the RPC 
command issued by the client. If desired, the procedure list information is 
obtained from the data server information and is used to instantiate the RPC 
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Monitor object to start the timing of the current RPC. The GeiNext function 
then gets the next data server in the available server list based on the 
procedure type and\ if applicable, its argument list. In the "ANY" scenario, 
the DTP code indicates that the client's stored procedure could be sent to 
5 ANY data server in the server list supporting the server group. The DDS 
randomly selects a data server name from the server list. Additionally, an 
automatic retry mechanism may be included, so that the DDS selects another 
server from the list of available servers in the event the DDS is unable to 
connect to the first server selection. 

1 0 Next, the GetCmdCon function is called to get or make a connection 

to the selected data server. The SendRpcCmd function then sends the RPC 
command and its argument set, if any, to the data server. After processing 
by the selected DUSs, results are returned to the DDS. The GetSrvTyp 
function is then invoked and returns the DTP code back to the RPC Handler. 

1 5 The "ANY" scenario utilizes the pass through capabilities of the DDS Open 
Server to process the result set. Thus, the data stream returned from the data 
server may be sent to the Addressability server without disturbance. This is 
accomplished once the active command/connection object is obtained. 

Once the results are sent to the Addressability server, the DDS may 

20 issue a send done final to the Client indicating that the data transfer is 
complete. The EndRPC function is then invoked to stop the timing of the 
current RPC. Next, the data server object is released and the active RPC 
count is decremented. 

The "SPECIFIC" scenario, which is used to select a single, individual 

>5 server follows the same process as described above with respect to the 
"ANY" scenario except that the "SPECIFIC" scenario specifies rule based 
procedures or specific server procedures. The rule based procedure scenario 
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selects the appropriate data server based on the data distribution rules and 
boundaries while the specific server procedure scenario uses the server name 
associated with the stored procedure. 

The "ALL" scenario, which calls for a transaction to be directed to all 
5 data servers supporting the group, is processed as follows. Again, it should 
be understood that some or all of the steps next discussed may be omitted 
and additional steps may be added while still remaining within the spirit of 
the invention. Initially, the Client transmits an RPC request to the DDS. At 
this point, the DDS will raise an RPC event which is handled by the RPC 
10 Handler functionality of the DDS. Next, the RPC counter is incremented to 
indicate that an active RPC is present in the DDS. The user data 
corresponding to the Client thread properties then may be obtained, and the 
user connection information is set up. 

Once the prelirninary setup is accomplished, the RPC command and 
15 its arguments are retrieved from the Client request data stream. The DDS 
then obtains the appropriate data server information based upon the RPC 
command issued by the Client. If desired, the procedure list information is 
obtained from the data server information and is used to instantiate the RPC 
Monitor object to start the timing of the current RPC. The GetNext function 
then gets the next data server in the available server list based on the 
procedure type and, if applicable, its argument list. In the "ALL" scenario, 
the DTP code would indicate that the client's stored procedure is to be sent 
to ALL data servers in the server list supporting the server group. The 
GetNext, GetCmdCon and SendRpcCmd functions are iteratively called until 
25 the server list has been completely traversed. 

The GetCmdCon function is called to get or make a connection to the 
selected data server. The SendRpcCmd function then sends the RPC 
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command and its argument set, if any, to the data server. For every RPC 
command sent to the data servers, the SendRpcCmd function establishes an 
Open Client environment that sends the RPC message to the SQL servers. 
Results are returned from the data servers in a random order back to the 
5 Open Client environment in the RPC Handler. The RPC Open Client sends 
the results back to the DDS. The GetSrvTyp function is then invoked and 
returns the DTP code back to the RPC Handler and processes multiple result 
sets in this scenario. The active command/connection object is obtained and 
while there are active commands outstanding, the results are retrieved and 

10 sent to the Addressability server. The RPC Handler then sends a send done 
MORE indication to the DDS, sets the command/connection to inactive and 
sends the MORE indication to the Addressability server. The MORE 
indicator informs the Addressability server to wait for additional results. As 
results are sent to the Addressability server the connections are marked 

1 5 inactive to indicate that the results were retrieved from the data server. 

Once all of the results are returned to the DDS, the DDS issues a send 
done final to the data server, and ultimately, to the Client indicating that the 
transaction is complete. The EndRPC function then is invoked to stop the 
timing of the current RPC. Next, the data server object is released, and the 

20 active RPC count is decremented. 

Utility Functions 

A set of utility functions, described below, have been developed to 
support the operations of the DDS. 
Command Connection Pool Service 
25 The CmdConPoolSrvc object provides a mechanism to close all 

connections that have met or exceeded a time out limit. The time out limit 
is the period of time this process sleeps which is a DDS Open Server 
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configurable time threshold. 

The CmdConPoolSrvc object does not have any input parameters. 

The CmdConPoolSrvc object provides output information to the DDS 
Error Handler which is directed to standard error and/or the DDS log file. 
5 The CmdConPoolSrvc object returns CS_SUCCEED or CS FAIL. 

Free Parameter Memory 

The FreeParamMem object frees any allocated memory associated 
with the Remote Procedure Call parameters passed by the Client application. 
This object first cheeks if any parameters exist and frees all the allocated 
10 memory. 

The FreeParamMem object accepts the following input parameters. 
paramCnt - An integer count of the number of parameters associated 
with the RPC Name. 

fmtPtr - A pointer to a data format structure that will contain the 
1 5 format of the data received from the Client in the RPC Handler. 

paramDataPtr - A pointer to an<array of pointers that will contain the 
actual RPC command parameter values. 

paramLenPtr - An integer pointer that contains the length of each of 
the parameter values. 

indPtr - A small integer pointer that is require to hold the null 
indicator for each parameter supplied by the client process and is required 
to bind the local variables. 



20 
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The FreeParamMem object does not output any information to 
standard output. 

The FreeParamMem object does not return any values to the calling 

object. 
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Get RPC Command 

The Get RPC command object is used in the RPC Handler and 
obtains the name of the client supplied Remote Procedure Call and the 
associated parameters, if any. If parameters exist, this object allocates 
5 memory for the local variables, binds the parameter to the local variables, 
and transfers the data from the TDS to the local variables. 

The GetRpcCmd object accepts the following parameters: 
srvProcPtr - Service thread pointer for the current Client thread. 
rpcNamePtr - A character string that points to the Client supplied 
10 stored procedure name. 

paramCnt - An integer count of the number of parameters associated 
with the RPC Name. 

frntPtr - A pointer to a data format structure that will contain the 
format of the data received from the Client in the RPC Handler. 
1 5 paramDataPtr - A pointer to an array of pointers that will contain the 

actual RPC command parameter values. 

paramiLenPtr - An integer pointer that contains the length of each of 
the parameter values. 

indPrr - A small integer pointer that is require to hold the null 
10 indicator for each parameter supplied by the Client process and is required 
to bind the local variables. 

All the input parameters, except for the service thread pointer, are 
passed to the GetRpcCmd by reference. 

The GetRpcCmd object does not provide any output to the standard 
^5 output. All data is returned to the calling object through the input 
parameters which are passed by reference. 

The GetRpcCmd object returns CS_SUCCEED or CS FAIL to the 
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calling object. 

Install Registered Procedures 

The InstallRegProcs object is the single point of installation of all the 
registered procedures stored in the DDS Open Server application. The 
5 InstallRegProcs object defines and creates all the registered procedures and 
any associated parameters in the Open Server registered procedure list table. 
In a preferred embodiment, this object installs the following registered 
procedures, which are presented in connection with the discussion on 
registered procedures. 
10 • OsShutdown 

SetFilter 

• SetLogFIag 

• MonLog 

• MonRpc 

The InstallRegProcs object does not accept any input parameters. 
The InstallRegProcs object does not provide any output to standard 

output. 

The InstallRegProcs object returns CS_SUCCESS or CS_FAIL to the 
calling object. 

20 Process Command Line Ar gument* 

The ProcArgs object processes the DDS command line arguments 
whenever the DDS is started. The command line arguments are extensive, 
but they allow the user to dynamically control how the DDS is conFig.d on 
startup. The DDS argument list provides the ability to control at least the 

25 following parameters: 

NETBUFSIZE is used to set the maximum size of the network I/O 
buffer to be used by the client connections. NUMREMBUF controls the 
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window size used on server-to-server connections. It indicates the maximum 
number of packets that may be outstanding on a logical sub channel before 
an acknowledgment is required. NUMCONNECTIONS indicates the 
maximum number of physical network connections the Open Server 
5 application will accept. 

NUMTHREADS specifies the maximum number of treads available 
to the DDS application. 

LOGFLAG is a flag that directs the error message to either standard 
error, the log file or both. 

10 NUMREMSITES indicates the maximum number of remote server 

site handlers that can be active at a given time. 

STACKSIZE defines the size of the stack allocated for each thread. 
SERVERNAME specifies the name of the DDS application. 
The ProcArgs object accepts the following input parameters: 
1 5 argc - An integer count of the number of arguments presented on the 

command line 

argv - An array of character string pointers that contain the actual 
input parameter values. 

nonSybProps - An class object that is passed by reference to hold all 
20 the non Sybase Open Server properties. 

The ProcArgs object provides a usage statement to standard error if 
an invalid argument is detected on the command line. 

The ProcArgs object returns CS SUCCEED or CS FAIL. 
Process Configuration 
25 The ProcConfig object opens the dds_config.dat file and configure 

the DDS application with any of the specified properties and flags. The 
properties and flags are the same as the command line settable properties and 
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flags. Also, if any command line properties and flags are specified when the 
DDS is started, the command line options override configuration file 
properties or flag settings. The ProcConfig object ignores properties or flags 
that are misspelled or missing any required argument. 
5 The ProcConfig object accepts the following input parameters: 

ctxptr - A pointer to the context structure for the DDS Open Server 

application. 

nonSybProps - A class object passed by reference to record any non 

Sybase Open Server properties that need to be set in the DDS Open 
0 Server application. 

This object outputs error information through the DDS Error Handler 
functionality to standard error and/or the Open Server log file. 

The ProcConfig object returns CSSUCCEED or CS_FAIL 
Send RPC Command 

The Send RPC command object sends the RPC command and its 
parameters to the remote data server. This object constructs a character 
string that contains the database name and the RPC name and issues a Client 
command to the destination data server along with any associated RPC 
parameters. 

The SendRpcCmd object accepts the following parameters: 
cmdPtr - A pointer to the command structure, that is used to send 
commands to a server. 

rpcNamePtr - A character string that contains the Client supplied RPC 
command name. 

dbname - A character string that contains the name of the database 
that contains the RPC command. 

paramDataPtr - A pointer to an array of pointers that will contain the 
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actual RPC command parameter values. 

fmtPtr - A pointer to a data format structure that will contain the 
format of the data received from the client in the RPC Handler. 

paramCnt - An integer count of the number of parameters associated 
5 with the RPC Name. 

paramLenPtr - An integer pointer that contains the length of each of 
the parameter values. 

indPtr - A small integer pointer that is require to hold the null 
indicator for each parameter supplied by the Client process and is required 
1 0 to bind the local variables. 

The SendRpcCmd object does not provide any output to the standard 

output. 

The SendRpcCmd object returns CSSUCCEED or CSFAIL to the 
calling object. 

1 5 The SendRpcCmd object constructs an error message and sends the 

message to the DDS Error Handler. 
Server Message Callback 

The ServerMsgCB object accepts the following input parameters: 
ctxPtr - A pointer to the context structure for which the message 
20 occurred. 

conPtr - A pointer to the connection structure for which the message 
occurred. 

srvMsg - A pointer to the CS_SERVERMSG structure containing 
server message information. 
25 The ServerMsgCB object provides an output message that is logged 

with the DDS Error Handler object that outputs the message to standard 
error and/or the Open Server log file, or both. 
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The ServerMsgCH object only returns CSSUCCEED. 

In addition to the above DDS utility functions, a set of general utility 
functions have been developed to support the general operations of the DDS 
application. 
CONNECT SERVER 

The connect server object establishes a connection to the specified 
data server using the login user id and password parameters. This object 
allocates a connection pointer structure for the specified context of the DDS, 
sets the connection properties for user name and password, and establishes 
the connection to the data server. 

The ConnectServer object accepts the following input parameters: 

ctxPtr - A pointer to the context structure. 

conPtr - The address of a pointer of a newly allocated connection 
structure. 

sqlsrv - A character string that contains the name of the data server 
to be connected to. 

usrld - A character string that contains the Client users identification 
used to connect to the data server. 

pswd - A character string that contains the Client password used to 
connect to the data server. 

The ConnectServer object provides no information to standard output. 
The ConnectServer object returns CS_SUCCEED or CS_FAIL. 
Get User Information 

The GetUserlnfo object accesses the thread properties and extracts the 
user id and password associated with the internal thread control structure. 
The GetUserlnfo object accepts the following input parameters: 
srvProcPtr - A pointer to an internal thread control structure 
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usrld - A character string pointer that will contain the user 
identification from the thread properties. 

pswd - A character string pointer that will contain the user's password 
from the thread properties. 
5 The GetUserlnfo object provides no information to standard output 

or the DDS Error Handler. 

The GetUserlnfo object returns CSSUCCEED or CSFAIL. 
Manage Format Pointer 

The ManageFmtPtr object provides the capability to set and/or 
10 retrieve a pointer to the format array in the remote server control structure. 

The ManageFmtPtr object accepts the following input parameters: 

srvProcPtr - A pointer to the thread control structure 

action - An integer value that specifies whether to get the format 
pointer, set the format pointer, or clear and release all allocated format 
1 5 structures 

type - An integer value that indicate whether to process a regular row 
format pointer or a compute row format pointer. 

computeld - an integer value that contains a compute identification 
of the format array which is returned to the calling object. 
20 fmtCtlPtr - A pointer to the format control structure 

fmtPtrPtr - An address to a pointer to the data format structure. 

The ManageFmtPtr provides no information to standard output or the 
DDS Error Handler. 

The ManageFmtPtr returns CS SUCCEED. 
25 Pass Results 

The PassResults object receives RPC command results from the data 
server and passes the data packets directly through to the requesting Client 
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object without disturbing the TDS packet. 

The PassResults object accepts the following input parameters: 
srvProcPtr - A pointer to the thread control structure. 
cmdPtr - A pointer to the command control structure. 
5 The PassResults object provides no information to standard output or 

the DDS Error Handler. 

The PassResults object returns CS_SUCCEED or CS_FAIL. 
Process Status Message 

The ProcStatusMsg object reads the return status code from a remote 
10 data server and returns the status to the client. The calling object is 
responsible for sending the serve send done to the client. 

The ProcStatusMsg object accepts the following input parameters: 
srvProcPtr - A pointer to the thread control structure. 
cmdPtr - A pointer to the command control structure. 
1 5 The ProcStatusMsg object provides no information to standard output 

or the DDS Error Handler. 

The ProcStatusMsg object returns CS SUCCEED or CS FAIL. 
Send Results 

The SendResults object processes DUS(s) results that satisfy a client's 
20 request from one or more remote DUSs. The calling object is responsible for 
sending the Addressibility server the appropriate Serve MORE and the final 
Send Done to the Client and the Addressibility server depending on the 
completion level of the client request. 

The SendResults object accepts the following input parameters: 
25 srvProcPtr - A pointer to the thread control structure. 

cmdPtr - A pointer to the command control structure. 

cmdType - An integer representing the command type, 
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CS_RPC_CMD. 

fmtCtlPtr * A pointer to the format control structure. 
The SendResults object provides no information to standard output 
or the DDS Error Handler. 
5 The SendResults object returns an integer - 1 when an error condition 

exists or the number of rows processed. 
DDS Registered Procedures 

Several registered procedures have been developed to support 
administrative functionality for the DDS Open Servers. 
10 Open Server Shutdown Features 

The shutdown registered procedure, OsShutdown, provides a system 
administration tool that gracefully shuts down an open server application. 
A password is obtained from the command line to shutdown the open server. 
The OsShutdown registered procedure checks for any active RPC requests 
15 running against the DDS and returns control back to the systems 
administrator without shutting down^the Open Server. 

An active RPC request is defined as a Client issuing an RPC request 
for service through a DDS. 

If there are no active RPC requests, the OsShutdown registered 
20 procedure initiates the shut down of the specified DDS. The registered 
procedure accesses a globally defined DDS server table to obtain the valid 
password for the specified. DDS and validates the password against the SA 
provided password. If the password is valid, the registered procedure issues 
a stop event that shuts down the Open Server. If the password is invalid, a 
25 message is logged to the error handler and returns control to the S A without 
printing a message to standard output. 

Upon receiving the shutdown request, the registered procedure locks 
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out any additional client transaction connections into the DDS Open Server 

application. 

Monitor Log Feature 

The monitor log registered procedure provides a mechanism that 
5 allows a client application to monitor the error and informational data being 
displayed in the DDS. The registered procedure, rp_mon_log, - log, allows 
a Client application to make a request to a DDS Open Server to monitor the 
log file activity of the specified DDS. The registered procedure utilizes 
several error handler member functions to determine if any other user is 
10 monitoring the log activity, to register the requesting Client thread with 
exclusive access to the monitoring functionality and a means to relinquish 
control of the monitoring functionality. The registered procedure call 
requires a valid password for the DDS and a time slice (in seconds) to 
monitor log activity. The log monitoring functionality permits only a single 
1 5 Client thread to access the monitoring functionality at any given time and 
relinquishes control of the monitoring fcinctionality when their time slice has 
expired. The Client application can interrupt the monitoring activity by 
dropping their connection to the DDS Open Server. 
Monitor RPC Performan ce Registered Procedure 
20 The monitor RPC performance registered procedure provides a 

mechanism whereby a client application may momtor RPC performance 
either near real-time or historically. At least two different types of 
monitoring may be initiated using SYBASE® RPC's. 

The registered procedure achieves near realtime reporting of RPC 
25 execution times when the @rpcoption parameter is equal to the string "ALL" 
or is a string containing a list of RPC's to be monitored. "ALL" is the default 
behavior for @rpcoption, so it need not be passed as an argument. The 
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procedure returns to the monitoring Client the RPC name, RPC Client spid, 
and the RPC's execution time for a duration of numseconds. Because all 
of this RPC information is being passed to rp mon rpc via a message queues, 
only one near real-time monitoring session may run at a time. 
5 The actual processing of the RPC information for near real-time 

monitoring is performed by the global MonRPCMsgQ object named 
G_monRPCMsgQ which is instantiated prior to the srv_run() for the DDS. 
The RPC handler instantiates a MonRPC object each time an RPC is being 
run, and a pointer to that object is what is put on the queue when the near 
10 real-time monitoring is active and the RPC is one being monitored. The 
activation and polling of the message queue, as well as the sending of 
results, is all performed by G_monRPCMsgQ->RunMsgQ(). 

The cumulative average monitor may be run by more than one 
monitoring client at a time because it merely parses and orders information 
15 contained in the global Xrefdatatbl procList. All this processing is 
performed by a TopRPCList object. This registered procedure ensures that 
the number of elements in the top list does not exceed the number of 
elements in the proclist so that no memory is wasted. All the processing 
needed to return result rows to the Client is contained in the TopRPCList 
20 object's member functions. The Client will receive rows containing the RPC 
name, the cumulative number of executions of the RPC, and the average 
execution time for the RPC. 

The only argument to the rp mon rpcO function is the SRV PROC*, 
which is needed by the G_monRPCMsgQ->RunMsgQ() for activating the 
25 message queue and ensuring only one monitor is polling the message queue 
at a time. Both G_monRPCMsgQ->RunMsgQ() and the TopRPCList 
constructor need the SRV PROC* to send results and messages back to the 
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monitoring client. 

A set of data flat files is maintained to support the non-database 
related data needed by the DDS. A discussion of each of these files as well 
as their purpose and structure follows. 
Data Server Na me File Definition 

The server name file, servers.dat, is used to store all of the available 
Data Server names that support the SMS. The DDS extracts the server 
names from this file and builds internal tables for quick delivery of server 
names to the requesting code The server name data file contains three 
attributes, the Server Names, the system administrator's ID, and a password. 
Each type of server is separated by a Server Type identifier. The Server 
attributes and the Server Type identifier is logically grouped together within 
the file. The password attribute is used to shut down the Open Servers in a 
graceful manner. 
15 DPS Con figuration File Definition 

The DDS Configurarion file contains configuration information that 
is used by the open server to set the Open Server properties on the startup of 
the DDS Open Server. The configuration parameters are specified in the 
file. 

20 Stored Pro cedure Req uirements 

The following stored procedures are required to retrieve the data from 
the Xref Server. The data returned is used to populate the appropriate Xref 
data tables. 

• Stored Procedure Name - LP_GET_PROCLIST - Retrieves a list of 
^ procedure names and related information. 

Logical Table Name - procedurejist 
Location - XRef Server 
Procedure Type - Group 
Database - xref 



BNSOOC1D: <WO__9724S76*1JU> 



WO 97/24879 




PCT7US96/20132 



65 

Input Parameters - Nothing or a valid stored procedure name 
Output Values - A list of the attributes of the store procedure(s) 
Procedure Text - As follows: 

create procedure lp_get_procJist@pname char(30) = "%" 
5 as 

begin 

select procedurename, 
groupname, 
procedure type, 
1 0 dtpcode, 

argumentjosition, 
rule name, 
servername, 
databasename 

15 from procedurelist 

where procedurename like @pname 

sort by procedure name 

end 

Stored Procedure Name - LPGETRULELIST - Retrieves a list of 
20 rule names and related information. 

Logical Table Names - ruleboundary and serverjist 

Location - XRef Server 

Procedure Type - Group 

Database - xref 
25 Input Parameters - Nothing or a valid rule name 

Output Values - A list of the attributes of the store procedure(s) 

Procedure Text - As follows: 

create procedure lp _get_rulejist @rule_name char(30) = H %" 
30 as 



begin 



select rule name, 

lowvalue, 



35 highvalue, 

r.servername 
from rule boundary r, serverlist s 

where r.servername = s.servername 

and 



BN8DOCID: <WO_0724078A1 JL> 



WO 97/24879 M M PCTYUS96/20132 



66 



end 



rulename like @rule name 
sort by rule name, lowvalue 



10 



Procedure Name - LPJ3ETSEVLIST - Retrieves a list of server 
names and related information. 

Logical Table Name - serverjist and server _group 

Location - XRef Server 
Procedure Type - Group 
Database - xref 

Input Parameters - Nothing or a valid stored procedure name 
Output Values - A list of the attributes of the store procedure(s) 
Procedure Text - As follows: 

create procedure lp_getj>erverjist @sname char(30) = 
as 



1 5 begin 



20 where 



end 



35 



select servername, 
warmserver, 
s.groupname 
from serverjist s, server group sg 

s.groupname = sg.groupname 
and 

s.server name like @sname 
sort by s.group name, s.server name 



25 • LP J3ET_PROC_COUNT - Retrieves a count of the number of 

procedures stored on the XRef Database. 

Logical Table Name - procedure list 

Location - XRef Server 

Procedure Type - Group 
30 Database - xref 

Input Parameters - Nothing 

Output Values - A count of all the store procedures 
Procedure Text - As follows: 



create procedure lp_get_proc cnt 
as 

begin 
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select count(*) 

from procedurelist 

end 

LP-GETRULECOUNT - Retrieves a count of the number of rules 
5 stored on the XREF Database. 

Logical Table Name -server Jist and ruleboundary 
Location - XRef Server 
Procedure Type - Group 
Database - xref 
1 0 Input Parameters - Nothing 

Output Values - A count of all the rules 
Procedure Text - As follows: 

create procedure lp_get_rule_count 
as 

15 begin 

select count(*) 

from rule boundary r, serverlist s 

where r. servername = s . servername 

end 

20 • LPGETS ER VER_COUNT - Retrieves a count of the number of 

servers stored on the XRef Database. 

Logical Table Name - server list and server group 

Location - XRef Server 

Procedure Type -Group 
25 Database - xref 

Input Parameters - Nothing 

Output Values - A count of all the servers 

Procedure Text - As follows: 

create procedure lp_get_server_count 
30 as 

begin 

select count(*) 

from server list s, server_group sg 

where s.group_name = sg.groupname 

35 end 

LP_GET_S R VGRP-COUNT-Retrieves a count of the number of 
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server groups stored on the XRef Database. 
Logical Table Name - server-group 
Location -XRef Server 
Procedure Type - Group 
5 Database - xref 

Input Parameters - Nothing 

Output Values - A count of all the server groups 

Procedure Text - As follows: 

create procedure lp_get _srvgrp_count 
10 as 

begin 

select count(*) 

from servergroup 

end 

15 A method and system for achieving client or customer-site processing 

of Client transactions in a distributed database environment has been 
described in detail above. As a result of such description, the advantages of 
the present invention will be apparent to those skilled in the art. While the 
invention has been described in conjunction with preferred embodiments, it 

20 is evident that numerous alternatives, modifications, variations, and uses will 
be apparent to those skilled in the art in light of the foregoing description. 
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CLAIMS 
We claim: 

1 A distributed database system for processing a client or customer-site 
initiated on-line database transaction comprising: 
5 a transaction generator, which initiates at least one database 

transaction, including information identifying service location equipment and 
a desired product, and transmits said at least one transaction to a dispatcher 
means for tracking a geographic location of said generator, for routing each 
of said at least one transactions to a geographic system, and for queuing each 
10 of said at least one transactions within a queue; 

transaction transfer means for retrieving said at least one transaction 
from said queue and transmiting said at least one transaction to interrogation 
server means; 

wherein said server interrogation means for interrogating data 
15 extraction means, which extracts said information identifying said service 
location equipment and said product from said transaction, formulates an 
addressability change transaction, and transmits said change transaction to 
said server interrogation means; and 

wherein said server interrogation means transmit said change 
20 transaction to an addressability change means for identifying controller 
means for enabling and disabling said desired product, and for instructing 
said controller means to update the status of said product. 
2. The system of claim 1, wherein said transaction generator comprises 
a local order RF transmitter for rransirutting said client-site initiated on-line 
25 database transaction, a local order RF receiver-convertor for receiving said 
transaction and converting said transaction to a computer readable format, 
and a modem for data linking said transaction to said queue. 
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3 The system of claim 2, wherein said local order transmitter comprises 
a transaction keying and RF transmitting device and a transaction RF 
transmission relay device. 

4. The system of claim 1 , wherein said queue is a persistent queue. 

5. The system of claim 1, wherein said server interrogation means 
includes a rules database controlling the interrogation of said data extraction 
means. 

6. A distributed database system for processing a client or customer-site 
initiated on-line database transaction comprising: 

a portable transaction generator, which initiates a database 
transaction, including information identifying service location equipment and 
a desired product, and transmits said transaction to a queue; 

a client message server, which retrieves said transaction from said 
queue and transmits said transaction to a data directory server; 

wherein said data directory server interrogates at least one of a 
plurality of dispatch utility servers to identify an available dispatch utility 
server and routes said transaction to said available dispatch utility server; 

wherein said available dispatch utility server extracts said information 
identifying said service location equipment and said product from said 
transaction, formulates an addressability change transaction, and transmits 
said change transaction to said data directory server; 

wherein said data directory server transmit said change transaction to 
an addressability open server; and 

said addressability open server identifies a controller, which controls 
enabling and disabling said desired product, and instructs said controller to 
update the status of said product. 

7. The system of claim 6, wherein said transaction generator comprises 
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a local order RF transmitter for transmitting said client-site initiated on-line 
database transaction, a local order RF receiver-convertor for receiving said 
transaction and converting said transaction to a computer readable format, 
and a modem for data linking said transaction to said queue. 
5 8. The system of claim 7, wherein said local order transmitter comprises 
a transaction keying and RF transmitting device and a transaction RF 
transmission relay device. 

9. The system of claim 6, wherein said queue is a persistent queue. 

10. The system of claim 6, wherein said data directory server includes a 
10 rules database controlling the interrogation of said at least one of a plurality 

of dispatch utility servers by said data directory server to identify said 
available dispatch utility server. 

1 1 The system of claim 6, wherein said transactions comprise remote 
procedure calls. 

15 12. The system of claim 6, wherein said plurality of dispatch utility 
servers operate in parallel to process a plurality of said database transactions 
concurrently. 

13. The system of claim 6, wherein said plurality of dispatch utility 
servers operate in parallel to formulate a plurality of said addressability 

20 change transactions concurrently. 

14. The system of claim 6, further comprising a plurality of controllers 
operating in parallel to process a plurality of said database transactions 
concurrently. 

15. The system of claim 6, further comprising a plurality of controllers 
25 whereby an appropriate addressability change remote procedure call is 

formulated based on said client-site equipment. 

1 6. A method of processing client or customer-site initiated on-line data 
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transactions comprising the steps of : 

initiating a data transaction, including information identifying service 
location equipment and a desired product, at a service location and 
transmitting said transaction to a queue; 
5 retrieving said transaction from said queue and transmitting said 

transaction to a data directory server; 

interrogating at least one of a plurality of dispatch utility servers to 
identify an available dispatch utility server and routing said transaction to 
said available dispatch utility server; 
10 extracting said information identifying said service location 

equipment and said product from said data transaction, formulating an 
addressability change transaction and transmitting said change transaction 
to an addressability open server; and 

identifying a controller, which controls enabling and disabling said 
desired product, and instructing said controller to enable or disable said 
product. 

The method of claim 16, wherein said queue is a persistent queue. 
The method of claim 16, further comprising the step of establishing 
rules whereby the interrogation of said at least one of a plurality of dispatch 
20 utility servers by said data directory server to identify said available dispatch 
utility server is controlled. 

19. The method of claim 1 6, wherein said transactions comprise remote 
procedure calls. 

20. The system of claim 16, wherein said plurality of dispatch utility 
25 servers operate in parallel to process a plurality of said database transactions 

concurrently. 

21. The system of claim 1 6, wherein said plurality of dispatch utility 



15 



17. 
18. 
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servers operate in parallel to formulate a plurality of said addressability 
change transactions concurrently. 

22. The system of claim 16, further comprising a plurality of controllers 
operating in parallel to process a plurality of said database transactions 

5 concurrently. 

23. The system of claim 16, further comprising a plurality of controllers 
whereby an appropriate addressability change remote procedure call is 
formulated based on said client-site equipment. 
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